填补安全与开发团队之间鸿沟的四个关键
安全和开发之间的关系往往无法获得最佳的处理。这不是谁的错，而恰恰是他们工作的本质。安全团队最首要的目标是保护组织不受应用安全问题的威胁。不幸的是，由于开发团队和安全团队经常各自为政，所以他们往往会互相争夺优先级，从而在工作上产生摩擦。
这些摩擦会使开发团队产生一种恐惧文化，也就是说，开发人员已经习惯了安全团队责怪他们出错。这对开发人员的工作并没有任何帮助，也无法使他们在开发时避免安全问题。而我们需要的是，将恐惧文化转变为责任共担，从而实现对安全风险的快速响应，并将其修复。正如Cisco公司的 Wendy Nather 所说：安全建议是用来采纳，而不是被迫执行的。
与其检查开发人员在应用开发过程中产生的错误，倒不如评估安全问题的响应及修复速度。所有人都希望开发的应用是安全的。所以我们需要将安全和开发无缝地集成到一个工作流程中。
这要从安全团队如何与开发人员合作开始。在那些打破条条框框并消除摩擦的团队中，安全建议往往有四个属性，这些建议可以简化工作流程，协调开发人员与安全人员的合作。
可理解的安全
对于一个开发人员来说，最让人苦恼的莫过于，从安全部门那里，收到一份25页的文档，里面列出了正在开发的应用所需要注意的安全事项。这些文档往往是难以理解的，并且阻碍了开发的进度。这是由于文档是用针对安全团队的语言，而非是针对开发团队的语言来撰写的。
例如，如果安全团队嘱咐开发人员说：保护好授权码，使其免受未授权的披露和修改，那么大部分开发人员都不知道这是什么意思。无论多么重要的安全注意事项，如果开发人员不能理解的话，那么该安全事项也很难得到实施。如果安全团队能够以一种开发人员可以接受的方式提供指导，并用开发人员可以理解的语言来撰写安全文档，那么开发人员就能更好地解决安全问题。
可行的安全
清晰且容易理解的安全建议是最基本的。如果安全团队并不仅仅只是告诉开发人员什么需要修复，而是一并地告诉他们如何修复，那么开发人员的工作就会更加的轻松，并且安全团队提出的建议也能更快地得到实施。很少有开发人员精通安全，即使安全建议是可行的，开发人员仍要花费精力来弄明白如何才能修复安全缺陷。
要帮助开发人员更好地理解安全，就必须开门见山。开发人员不需要明白关于安全问题的种种细节，并且，强迫他们研究如何修补漏洞更是件费力不讨好的事。对于所有的开发人员来说，他们想知道的仅仅是你希望他们做什么。所以，通过提供可行的指导，来让他们尽快进入到绿色复选框吧。
自动化的安全
如果你已经以一种可理解的语言来告诉开发人员需要修复什么，并用可行的指导来使其明白该如何进行修复。那么，你可以进一步地以自动化的方式来解决问题吗？
安全与开发团队之间的矛盾，部分体现在：开发工作的高速率以及大量的自动化与安全工作的低速率以及自动化的匮乏之间的矛盾。安全团队应利用自动化来代替word文档，从而跟上开发团队的速度。这个过程需要预先投入大量的时间与精力。我们需要将自动化融入到安全开发流程中，以便在部署前后扫面潜在的安全问题。
当安全团队运用与开发团队同种类型的自动化时，他们就能够更加无缝地融入到工作流程中。
适时的安全
安全应该被尽早地安排进开发流程，并融入到现有的开发生命周期以及工作流程中。而不是等到下一个阶段或下一个月，开发人员才得到安全指导。
如果在合适的时间就引入安全性，那么开发人员在应用开发的初期，就可以弥补安全与设计之间的差距，而不是等到部署应用之后才修补。
这种“左移”降低了风险的同时，也简化了开发人员与安全团队的工作流程。
结束恐惧文化
做出这些改变需要完成文化的转变。我们需要摆脱孤立的恐惧文化，转向集成的、现代化的、自动化的工作流程，让安全和开发团队共同承担责任。
这需要衡量成就——比如解决问题的速度，而不是衡量缺点。这种文化转变，将安全团队定位为开发人员值得信赖的顾问，并且创造了一种确保每一个应用在设计上就是安全的意识。
无论是开发团队还是安全团队，其最终目的都是服务于业务。由于两部门工作所针对的方面不同，难免会产生摩擦，所以处理好两部门的关系尤为关键。安全与开发团队之间有着互利共生的联系。在开发重视安全的同时，安全人员也应该站在开发的角度来有针对性地为其提供安全指导。
参考阅读